エクストリームプログラミング読書会 第六回

第6回

参加者：@ueda, @got4416, @kobatomo

進捗：5章 結論〜7章 いきいきとした仕事 まで(8ページ)

近況

XP本の「訳者あとがき」を読んで「パターン、Wiki、XP」を購入（中古） @ueda

訳者あとがきが、いいこと書いているよ。(@ueda)

もう少しプログラミング(Java、Go)をする。TDD写経中(@got)

エンジニアのためのデザイン思考入門を読んでます(@kobatomo)

UdonPy開催するよ！(@kobatomo)

5章 原則

結論

@kkd

原則がしっかりおさえられていると、プラクティスにとらわれなくなるのだなぁ（今更）

@ueda

原則の理解。ということは、迷うことがあればこの5章の各項目を当てはめて考えてみれば良い。

時間が経つと原則って何かと５章を振り返る。

@kobatomo

なんのために、どんな目的があってそれを使うのか。目的が大事だよってことですよね。

@got4416

「振る舞いの指針」となる原則。XPに関わらず頭に留めておく原則ばかりでした。

方向性として理解

頭の中に留めて動けたらなぁ

6章 プラクティス

@ueda

ペアで「チェックボックスにチェックを入れる」ような作業を強いられた苦い思い出

ふと孫子の兵法を思い出した。（アグレッシブな手法）

単純作業をペアでやるなんて生産性悪い。＞＞これは良くないよね。

@got4416

「プラクティスだけでは味気ない」→価値のあるプラクティスも「価値」忘れると意味がなくなる？

7章以降は試せていないプラクティスが多いが「プラクティスを仮説として使い、XPの実験をしてみてほしい」に心が少し軽くなった。

少しずつ進めていこう。

@kobatomo

導出プラクティスって何だろう。どの価値と結びついてくるんだろう。このあとが楽しみ。

@kkdに質問

経験上、どのプラクティスが導入しやすいのかー。(@got) 次回のミーティングの際に聞く。

何に困っていますか？（@kkdの質問を思い出すと良い)(@ueda)

導入しやすさ（やりやすさ）と、困り事の重要度（切実度＝成果の価値の高さ）のバランスで決めるのが良い(@kkd) その人の立場もあるしね（開発者なのか、経営者なのか、中間管理職なのか）

「〜したいけど、XXXだ」のような「葛藤」が現場でかならずあるので、その葛藤を考慮するのが重要

「プラクティス」という単位では大きすぎる（実施するのにハードルが高すぎる）場合があるので、小さく刻むのが重要

7章 主要プラクティス

全員同席

@ueda

前々職、前職、いずれもパーティションで仕切られた個人スペースありましたが、オープンスペースと両方という環境はなかった。

客先常駐的な仕事の場合は、オープンスペースと言っても意味が違いますね。電話も鳴るし。

@kobatomo

現状弊社は、机の前のパーティションは、無くなった。２年前に撤去した。（モニターによる擬似パーティションは残る）

全員同席することで、プロジェクトの生産性が高まるのは、相談しやすくなるからだと考える。実際、こちらからの発信はしやすくなった。ただ、相談されることは少ないので、相談しやすい雰囲気づくりはできていないのではと思ったが、やってる仕事が違うので、同じ部署（場所）でも相談されないこともある。

@got4416

「集団で達成する安心感」って人それぞれだから一筋縄では行かなそう。

職場の机の上は奇麗ではないんですが、通常は数日程度で捨られる（予定の）書類置き場だけど、人が相談に来た時に相談スペースとして利用できるようにしています。（立ち話は何だからと空き椅子を見つけて座らせて、捨てる書類の裏で話しながら絵を描いたり）

落ち着いて少し深い話もできる

自分のスペースを一部提供して

親密な関係をきづけているが、時間忘れて話すことがある（反省）。

チーム全体

@ueda

チーム感を感じることが少ない人生だった...

タスクの切り替え時間って確かにムダだなぁ。気分転換にはなるかも。

今は、Agileを勉強して外部の人とどうやっていくのかを常に考えながら仕事をしている。

スクラムとかベロシティとかを聞くと、すごいチームと思ってしまう。

@kobatomo

12人も大変そう。多分自分は、その半分くらいかな。150人の規模感は、想像できない。

チームに属しているが、チームの主プロジェクトから離れ、別のプロジェクトを実施しているため、疎外感を感じている。

ただ、今の自分のお客様へはきちんと価値を提供していくことを一番大事にして仕事しています。

別プロジェクトをやりつつ、他プロジェクトをやることは、難しい。タスクの切り替えは仕掛かりを作ってしまうので基本的には嫌です。

@got4416

スキルや考え方を「身に付けた人を迎え入れる」どうすればできるんだろうか？

今いる人だけで頑張ってしまうから、結果としてボロボロになってしまうこともある。

人月換算の仕事なので、「小数点以下の人間を入れる」ケースそのまま。後に出てくる「いきいきした仕事」に記載されている「時間の使い方の管理」のやり方で対応しているが・・・

「時間の使い方の管理」は、共感できます。(@kobatomo)

情報満載のワークスペース

@ueda

壁に貼られたストーリーというのが、自分としては苦手かも。全体像はなんとなく頭に入れておいて、当面の課題に集中したい。

全体を見ると、いろいろなことが気になって（心配になって）当面の課題（仕掛かり中）以外の調べ物ばかりに走ってしまったり。

@kobatomo

他の人のタスクボードに動きがない。チームにとっての価値がないということかな？

個人的には抱えず、出し切る方が良いので活用中。

着実に進捗させなければいけない課題をチャートに張り出したのに、チャートの更新が滞れば外す？これは良いの？

原因究明に時間がかかる時とか？どうする？(@kobatomo)（細分化して動かすと良いのでは？@ueda）

Trelloを使っているよ。本当に動かない時は、まずは、Doneにしている。本当に動かすカードをDoingに移行している。(@ueda)

@got4416

ホワイトボードと付箋を買って使わずに止まってる！

情報を誰が見るか、「チーム」をどこまでの範囲と捉えるかで、考え方が変わりそう。

開発者（もしくは自分）だけが見るのであれば表計算ソフトの成果物を共有すればいいけど、きっとそうではない。

WBS(Work breakdown structure?)

タスクを決めるときには、Kickoffしてチームとして共通認識を持っている粒。（@kobatomo)

ホワイトボードは、何もアプリを開かなくても可視化できるメリットある。(@ueda)

明日から、まずは小さく、やってみる。(@got)

いきいきとした仕事

@ueda

平日は9pm-10pm頃まで仕事をしていることが多かった（過去形）。日中は雑務とかメールのやり取り、調べもの等で開発に集中できるのが夕方からとか、まぁよろしくない習慣(昔）。

@kobatomo

遅れをリカバリーするために長時間労働してしまうのはある。

長時間労働して疲労していくると、頭が重くなる。これが自分の症状。

これをみて、定時に帰ろうとした２０１７年でした。

@got4416

仕事も私生活も同じなんだと思う。＞「病気の時は休息と回復に努め」

自分が生み出しているバリューの計測方法ってあるの？（気づく方法ってあるの？

残業時間になったらイヤホンしてすべてをシャットアウトしていたが若い頃がありました・・・

@kkdに質問

自分が生み出しているバリューの計測方法ってあるの？（気づく方法ってあるの？ 「バリュー（価値）」ってなんだろうね？をまず話し合うのがいい。 ソフトウェアが生み出す価値とは何か？ 誰の、何のために使っているか、その結果、使う人の何をどう変えているのか？、どのくらいの利益を生み出しているのか？（数字）

顧客に「ありがとう、おかげでXXXができるようになりました」って言われている？

今日のふりかえり

いつもより密に話ができた。（仕事場を想像しながら)@ueda

タスクボードをやってみるよ。(@got)

皆さんがやってるプラクティスを聞けて良かった(@kobatomo)

次回

2018/1/24 19:30 - 21:00

connpass : kobatomo

wiki : kobatomo

hackmd : got

司会 : ueda

範囲 : ペアプログラミング - 7章全部